Challenges of a type error slicer for the SML language

SML (a higher-order function-oriented imperative programming language) depends on automated inference of sophisticated type information. Existing implementations have confusing type error messages. Type error slicing gives the programmer more helpful type error information: (1) It identifies all program points that contribute to a type error rather than blaming just one point. (2) It exhibits a slice of the original program’s syntax instead of showing an internal representation of some program subtree which may have been substantially transformed. (3) It avoids showing internal details of inferred types which were not written by the programmer. A type error slice contains all information needed to understand the error, and avoids irrelevant information. Similar to other previous work for better handling of type errors, type error slicing was initially developed for a very tiny toy language: the formal work was for a core barely larger than the λcalculus, and the implementation had only a few additional primitives. Extending type error slicing to a full programming language is extremely challenging, and to do this for SML we needed a number of innovations. Some issues would be faced for any language, and some are SML-specific but representative of the complexity of language-specific issues likely to be faced by other languages. As an example of a generic issue, the known ways of generating constraints that avoid an explosion in the number of constraints conflict with the need to exclude program parts that are irrelevant to errors, so we developed new ways of handling constraints. As an example of a SML-specific issue, the syntactic class of identifiers in SML depends on earlier declarations, but passing an environment as input makes it more difficult to ensure that error slices cover the right amount of program text, so we developed context sensitive constraints that avoid needing to know identifier syntactic class. Other issues include such things as how to indicate (ir)relevance of various program details, handling also context-sensitive syntax errors, and integration with a program editor. A bonus is that our methods in effect also provide a compositional (bottom up) type inference algorithm for the SML language, which may be useful for reasons other than type error explanation.